<html><head><title>OpenFlowIntroduction</title></head><body bgcolor="#ffffff">
<table bgcolor="#eeeeff" border="0" cellpadding="3" cellspacing="0" width="100%">
<tbody><tr>
<td valign="bottom">
<h1>
<a href="http://www.openflow.it/Documentation/documentation/"><img src="OpenFlowIntroduction_fichiers/ZWikiPage_icon.gif" valign="bottom" alt="to FrontPage" border="0" height="32" width="32"></a>
<a href="http://www.openflow.it/Documentation/documentation/OpenFlowIntroduction/backlinks">OpenFlowIntroduction</a>
</h1>
</td>
<td align="right" bgcolor="#eeeeff" valign="top">&nbsp;
</td>
</tr>
</tbody></table>
<p>
<!-- end of default_wiki_header -->





</p><h3>Openflow: an introduction</h3>
<h4>  An activity based workflow management system</h4>
<p>    Openflow is an activity based workflow management system. Being <em>activity based</em>
means that the processes, the workflows, are made of activities to be
completed in order to get something done. This differs from entity
based workflows where the focus is set on a given document and the
states it has to go through in order to be completed.</p>
<p> For example, the process describing a research in your campus
library can be handled as an activity based process: you have to get a
signed authorization by your teacher, go find your books of interest
using either the computer catalogs or the librarian's help, and then
check-out the books you need (signing the appropriate stuff). This is a
list of activities to be carried out in order to get some books out of
the library. There is no main document in this process.</p>
<p> Another example of an activity based process might be represented
by the fund request submission process. A teacher of the university has
to submit a request for buying a new computer. The process starts by
filling in a form where the teacher specifies what he intends to buy
and how much this costs. The form will be handled by the administration
office and, if the total cost goes beyond a given threshold, it
requires the personal authorization by the administration chief. Budget
is then checked to see if the teacher has appropriate funds left for
the acquisition. In the end an e-mail is sent to the teacher telling
him the result of the submission; the request is filed in the request
archive and the funding database is updated subtracting the requested
cost from the available money left. This process has a main document
(the request) but it has a lot of side actions to be carried out as
well: signed authorization, archive insertion, database update, e-mail
sending. The best way to describe this is through an activity based
workflow, where the process is made of activities to be carried out.</p>
<p> On the other hand simpler processes do not require the complex
structure of an actvity based workflow management system, and a simple
entity-based workflow would suffice. For example the publication of
documents on a web site can be simply modelled by the given document
going through the states of new, submitted, and then approved or
rejected. In such workflows the document is the main issue, and its
available actions are defined by its current state.</p>
<h4>  Main issue</h4>
<p>    The main issue for a workflow management system is answering the question "<em>who must do what, when and how</em>". In an activity based workflow management system (as Openflow) this question finds an answer.</p>
<h4>  <img src="OpenFlowIntroduction_fichiers/whowhatwhenhow.gif"></h4>
<p>    The process defining the sequence of activities to be carried out says <strong>what</strong> should be done and <strong>when</strong>
by the definition of activities and transitions. An activity (the what
part of the issue) represents something to be done: giving
authorization, updating a database, sending an e-mail, loading a truck,
filling a form, printing a document and so on. Transitions define the
appropriate sequence of activities for a process (the <em>when</em> part of the issue).</p>
<p>    Each activity will have an associated application designed to carry out the job: the <strong>how</strong> part.</p>
<p>    The <strong>who</strong> part is generally the user assigned to
carry out the activity, through its application. Usually activity
applications will be used by someone, a person, but in many cases the
entity assigned to an activity might be an automatic system. Afterall,
why should you have a person waste time updating a database if it can
be done in software directly?</p>
<h4>  Two reasons to use Openflow</h4>
<p> One reason to use a workflow management system is to improve the
efficiency and performance of the processes you usually handle. A lot
of activities you usually do can actually be carried out by an
automatic system. Database update, e-mail sending, research, document
archiving and so on are activities that a computer can carry out with
no need for human intervention. This means that the activity job will
be completed much faster <em>and</em> the human resources can be used in some more valuable way (and they will be grateful for that).</p>
<p> Another reason to use a workflow management system is to always
have the answer to the question "who must do what, when and how".
Formalizing your process means wasting no time in deciding what to do,
having each person performing the right job and being sure that your
process can be completed appropriately.</p>
<p>  </p><hr><p></p>
<h4>  The process definition</h4>
<p>    The goal of a process definition is to give answer the question "<em>who must do what, when and how</em>". Activities and transitions describe the process you want to model (the <em>what</em> and <em>when</em> part). You can see them as the "bubbles and arrows" description of what has to be done and when.</p>
<h4>  <img src="OpenFlowIntroduction_fichiers/bubblesarrows.gif"></h4>
<p>    Applications describe the <em>how</em> part and are associated with activities. Users and roles describe the <em>who</em> part.</p>
<h4>  Activities (what)</h4>
<p>    Each activity can be of three different <strong>kinds</strong>:
application, sub-process or routing. Usually each activity of the
process definition describes something that has do be done, some kind
of work. This work can be either carried out by an <em>application</em> or by a <em>sub process</em> definition that better refines the job to be done. Sometimes an activity will be assigned the simple job of handling the <em>routing</em> of work in the process. In this case the activity is just a dummy activity that simply chooses what to do next.</p>
<p>    Each activity has one <strong>incoming guard</strong> for collecting incoming transitions that lead to it. The activity incoming guard can be either set to <strong>and</strong> or <strong>xor</strong> for two different behaviour:</p>

<ul>
<li><em>and</em>: means that all the activities that lead to this activity have to be completed in order to enable this activity to work.</li>
<li><em>xor</em>: means that just one of the activities that lead to this activity has to be completed in order to enable this activity to work.</li>

</ul>
<p>    <img src="OpenFlowIntroduction_fichiers/joinsplitmode.gif"></p>
<p> Each activity also has one outgoing guard for collecting outgoing
transitions getting out of it. Again, the activity outgoing guard can
be either set to and or xor for two different behaviours:</p>

<ul>
<li><em>and</em>: means that this activity will trigger the work of all
the activities it connects to; doing this the flow in the process will
be split in parallel (concurrent) flows.</li>
<li><em>xor</em>: means that this activity will trigger the work of
just one of the activities it connects to, depending on condition
evaluation (see transitions below).</li>

</ul>
<p> Work performed by an activity will be triggered in different ways
as determined by the start mode setting of the activity itself. It can
be set to either:</p>

<ul>
<li><em>automatic</em>: the activity will run its application as soon
as an instance workitem reaches it. There will be no worklist for
users: it will be openflow itself taking care of starting the activity
application on the workitem.</li>
<li><em>manual</em>: openflow will wait for user intervention to start
the activity application: usually this is done through the call to the
"callApplication" API of workflow. This api should be called by the
worklist the user is using (like the default worklist in openflow does).</li>

</ul>
<p>    When an application completes its job the activity finish mode will be evaluated. It can be set to either:</p>

<ul>
<li><em>automatic</em>: as soon as a "completeWorkitem" api is called
(supposedly by the activity application upon ending its work) the
instance will be automatically forwarded to the next activity. In
manual finish mode this will not be done, and user (again, the activity
application upon user input) will have to call the "forwardWorkitem"
api. This enables the user to choose a given path (transition) for the
instance to follow. So mainly this mode is reserved for manually
steering the instance in alternative paths of the process. (Remember
that you can automatically steer the instance giving condition to
transitions: see below).</li>

</ul>
<h4>  Transitions (when)</h4>
<p> Transitions connect activities together. A transition connecting
activity A with activity B states that as soon as A is finished B has
to be started.</p>
<p>    Transitions can be guarded by conditions. A transition <strong>condition</strong>
will be evaluated if the "from" activity has choose one and only one
path to be followed (ie: the activity has a xor outgoing guard).</p>
<h4>  Applications (how)</h4>
<p> An application is assigned to each activity in order to carry out
the job the activity has to do. Applications can be anything triggered
by an <em>url</em> call: python scripts, dtml forms, sql queries, Zope
applications or even external applications like word or other custom
and dedicated applications.</p>
<p> What the application is required to do is to invoke the appropriate
api for interacting with Openflow. For example the application will
need to invoke the Openflow <em>completeWorkitem</em> to signal Openflow that its job is finished and a new activity can be started.</p>
<h4>  Users and roles (who)</h4>
<p>    Users are assigned to applications through roles.</p>
<p> The available roles for openflow are the zope-defined roles. To add
a role just add a zope role to the folder where you build your
application.</p>
<p> One user can be listed in one or more roles. Roles can list one or
more activities. Each user will be able to work on all activities
listed in roles he is listed in.</p>
<p>    Actually each role will keep three different lists:</p>

<ul>
<li><em>users list</em>: list of users assigned to the role</li>
<li><em>enabled activities</em>: list of process activities that users listed in this role can work on</li>
<li><em>assignable activities</em>: list of process activities that users listed in this role can assign to other users</li>

</ul>
<p>  </p><hr><p></p>
<h4>  The process instance</h4>
<p> A process definition gives the instructions for completing some
work. A process instance, in turn, is an actual execution of a process
definition.</p>
<p> For example, if the process definition describes what should be
done for submitting a fund request, a process instance of that process
definition is an actual submission for funding.</p>
<h4>  Workitems: tracking the history</h4>
<p>    We call <strong>workitem</strong> the execution of a single
activity of the process definition. Workitems are created every time an
activity is triggered. Workitems are never destroyed, even when an
activity completes its job, the workitem created to represent the
execution of that activity is just set to a <em>complete</em> state. A process instance is a collection of workitems: one per activity executed (or in execution).</p>
<p> One of the most important jobs of a workitem is to keep track of
events during the execution of its activity. Since the process instance
keeps track of all its workitems, and each workitem keeps track of all
the events that happen during the execution of the activity, the
complete history of everyting that has happened is recorded in each
process instance.</p>
<p>    This is very useful for two reasons:</p>

<ul>
<li>you can have access to an event log of every single instance begun in your process</li>
<li>you can learn from analysis of these reports how to better design
your process, considering load balancing, completion times, and so on.</li>

</ul>
<h4>  Worklist and assigning work</h4>
<p>    To each user is associated a <strong>worklist</strong>: a list
of workitems pending on activities the user is supposed to perform. The
worklist is not set to a given size: it grows when activities require
additional work to be done, and it shrinks as the work on activities is
completed.</p>
<p> Users are presented their worklists to let them know what is to be
done. In Openflow three policies exist for work assignment: <strong>pull</strong>, <strong>manual push</strong> and <strong>automatic push</strong>.</p>

<ul>
<li><em>pull</em> policy means that users will choose what to do, as if
the work to be done was gathered in a common pool where users go fetch
what they want to take care of</li>
<li><em>manual</em> push policy means the user is assigned work by another user</li>
<li><em>automatic</em> push policy means the user is automatically assigned work by the engine itself</li>

</ul>
<p> You can see this as having the process instance workitems assigned
to users: pulling will be self assignment and pushing will be
assignment by somebody else (or by the engine itself).</p>
<p> Whichever policy is used for assigning work, once a user is
assigned some work he will be the only one enabled to carry it out:
Other users will not see the assigned work in their worklist.</p>
<p>  </p><hr><p></p>
<h4>  Focus on flexibility</h4>
<p> In existing workflow management systems flexibility is a major
issue. When you design a process definition there is variable (and
usually low) chance the process you defined is actually the most
appropriate model you could get of the process.</p>
<p> It is very important to have a way to handle cases that go outside
of the set boundary, the "exceptions". At the same time it is also
important to have tools that let you change the process definition even
while it is running: it can be dramatic having to stop your processes
to change their definitions.</p>
<h4>  Exception handling</h4>
<p> Exception handling is necessary for unforeseen situations when
users have to handle something that the process was not designed to
handle.</p>
<p> Instead of a normal handling of a workitem the user can make it
"fall out" of the normal process flow. The fallen (exceptional) token
will then be available to any user assigned to handle exceptions. As
soon as the workitem is fixed, it can be inserted into any activity of
the process to resume the process flow. In this way the user can change
the workitem data anyway he wants, to adjust to the exceptional
situation.</p>
<h4>  Dynamic redesign</h4>
<p> A process definition can be changed while in execution (while
process instances run the flow). New activities can be added, old ones
deleted, transition created or changed and so on. Any invalidating
situation that might occur will be handled, causing the appropriate
workitem to fall out (go into exceptional state).</p>
<p> As soon as the process is changed all the current process instances
will read the new process definition as the definition to be used.</p>
<p> Dynamic redesign and exception handling are related to each other.
Exception handling allows for dealing with unforeseen events: it should
suggest changes in the process definition to handle that situation in
the future. On the other hand dynamic redesign will probably put some
(or all) process instances into an invalid state: exception handling
should be used to recover from these situations.</p>
<!-- start of default_wiki_footer -->
<p>
<table bgcolor="#eeeeff" border="0" cellpadding="3" cellspacing="0" width="100%">
<tbody><tr>
<td align="left" valign="middle">
<small><em>
Last edited 2004/09/24 11:43:25.300 GMT+2
</em></small>
</td>
<td align="right" valign="middle">
<a href="http://www.openflow.it/Documentation/documentation/OpenFlowIntroduction/editform">Edit this page</a>
</td>
</tr></tbody></table>

</p></body></html>